Skip to content

FLUTE version 2 (RFC 6726) signalling, off by default: step one of three, no conformance claimed - #65

Open
jordijoangimenez wants to merge 1 commit into
5G-MAG:feature/wave3-rfc6726-compliance-fixesfrom
jordijoangimenez:feature/flute-v2-support
Open

FLUTE version 2 (RFC 6726) signalling, off by default: step one of three, no conformance claimed#65
jordijoangimenez wants to merge 1 commit into
5G-MAG:feature/wave3-rfc6726-compliance-fixesfrom
jordijoangimenez:feature/flute-v2-support

Conversation

@jordijoangimenez

@jordijoangimenez jordijoangimenez commented Aug 11, 2026

Copy link
Copy Markdown
Contributor

Base branch. This pull request is based on feature/wave3-rfc6726-compliance-fixes, the head of
#62, not on development, because it builds on that work. The diff therefore shows only this pull
request's own single commit. GitHub will retarget it to development automatically when #62 merges.

Advances #81. Does not close it, and must not be set to.

Dependencies and issues

Depends on: #62, and is based on its branch, so #62 merges first.
Paired with: #61, #64, #68 and #98, independent of this one, either order.
Closes on merge: nothing. It advances #81 by one of the three steps that issue lists, and #81 must
stay open afterwards.

What is in this pull request

One commit. A per-session FLUTE version, defaulting to 1, plus every version 2 rule that differs
from version 1 except congestion control. Nothing here is reachable from a version 1 or 3GPP
session; each difference is behind the selector.

Area Version 2 behaviour
Signalling EXT_FDT version field set to 2, receive accepts only the configured version, RFC 6726 FDT namespace
LCT generation the two bits RFC 3451 used for Sender Current Time and Expected Residual Time size nothing and are stepped over by nothing, per RFC 5651; version 1 unchanged
FDT Instance ID wraps to the smallest expired identifier, refuses one still live, reports exhaustion (RFC 6726 cl. 3.4.1); version 1 keeps RFC 3926's wrap to zero
Expires read in the NTP era nearest the current time (RFC 6726 cl. 3.3)
Shared Content-Location the declaration from the greater FDT Instance ID wins, not whichever completed first (RFC 6726 cl. 3.4.2)
IPsec ESP association sets a replay window, which RFC 6726 cl. 7.5 requires via RFC 5775; version-independent

Checked and already met, so no code changed: EXT_TIME and EXT_AUTH recognition (RFC 5651 asks
only that they be recognised, not parsed); the RFC 3450 to RFC 5775 move, whose two substantive
items were already present; the FDT schema body, whose attribute set matches and whose 3GPP extras
the schema itself admits; and ESP authentication and integrity. README-FLUTE-V2.md records each
of these, how it was established, and where the evidence is a reading rather than a test.

Not implemented: congestion control. RFC 5775 requires it for every packet in a session. It is
a building block, not a patch. No RFC 6726 conformance is claimed for this branch and none can be
until that exists.
It is the only remaining item.

What this is not

This is not FLUTE version 2 support, and makes no conformance claim. #81 separates that into three
steps and this is the first. What this earns is that the version stops being hardcoded.

Correction to an earlier version of this description. It said of RFC 5775 and RFC 5651 that "neither
of the newer documents is held by us, so no version 2 conformance can be asserted either way". That was
wrong, and it kept #81's second step from being attempted: both documents are available and have now been
read against this code. The finding is recorded on #81. In short, the LCT header does not change between
RFC 3451 and RFC 5651 for any field this library uses, and RFC 5775 adds two things to RFC 3450 that are
both already present, so the second step needed four fixes rather than a re-encoding. Three of them landed
on #62 and one on #98, none on this branch; this branch stays a single commit.

What still blocks a version 2 conformance claim is the third step: congestion control, implemented in #98
and untested against a second implementation.

Version 1 stays the default because the profile this library's consumers operate, TS 26.517 clause 6.2.1
pointing at TS 26.346 annex L, is scoped to RFC 3926 throughout. That was @davidjwbbc's point on #62, and
it is why this material was split out of that branch rather than merged into it.

Verification

T1: 77 cases passing, including that a version 2 session signals 2 and a version 1 session is unchanged.
No live verification: there is no version 2 peer to test against, and none is claimed.

Merge order

After #62. Independent of the FEC branches.

@jordijoangimenez jordijoangimenez self-assigned this Aug 11, 2026
@jordijoangimenez jordijoangimenez added the enhancement New feature or request label Aug 11, 2026
@dsilhavy dsilhavy added this to the v1.0.0 milestone Aug 14, 2026
@jordijoangimenez
jordijoangimenez marked this pull request as draft August 14, 2026 10:27
@jordijoangimenez
jordijoangimenez force-pushed the feature/flute-v2-support branch from 6237b31 to b5be461 Compare August 22, 2026 12:57
@jordijoangimenez jordijoangimenez changed the title FLUTE version 2 on transmit (not 3GPP-compliant — reference/future work, depends on #62) FLUTE version 2 signalling, off by default Aug 22, 2026
@jordijoangimenez
jordijoangimenez changed the base branch from development to feature/wave3-rfc6726-compliance-fixes August 22, 2026 12:59
@jordijoangimenez
jordijoangimenez force-pushed the feature/flute-v2-support branch from b5be461 to 26dacc2 Compare August 22, 2026 13:16
@jordijoangimenez
jordijoangimenez deleted the feature/flute-v2-support branch August 22, 2026 13:22
@github-project-automation github-project-automation Bot moved this from In Progress to Done in MBMS: Support for FLUTE Aug 22, 2026
@jordijoangimenez
jordijoangimenez restored the feature/flute-v2-support branch August 22, 2026 13:24
@jordijoangimenez
jordijoangimenez changed the base branch from feature/flute-v1-profile-conformance to development August 22, 2026 13:24
@jordijoangimenez jordijoangimenez changed the title FLUTE version 2 signalling, off by default FLUTE version 2 (RFC 6726) signalling, off by default: step one of three, no conformance claimed Aug 22, 2026
@jordijoangimenez
jordijoangimenez changed the base branch from development to feature/wave3-rfc6726-compliance-fixes August 22, 2026 15:25
@jordijoangimenez
jordijoangimenez marked this pull request as ready for review August 22, 2026 15:38
@jordijoangimenez
jordijoangimenez force-pushed the feature/flute-v2-support branch 4 times, most recently from 798ddf8 to 1e97d70 Compare August 22, 2026 18:44
@jordijoangimenez
jordijoangimenez force-pushed the feature/flute-v2-support branch from 1e97d70 to 5a9496c Compare August 22, 2026 18:44
@jordijoangimenez
jordijoangimenez force-pushed the feature/wave3-rfc6726-compliance-fixes branch 2 times, most recently from 637cf46 to 12fb037 Compare August 22, 2026 19:02
@jordijoangimenez
jordijoangimenez force-pushed the feature/flute-v2-support branch 2 times, most recently from e033e91 to 0d009e8 Compare August 22, 2026 19:50
@jordijoangimenez
jordijoangimenez force-pushed the feature/wave3-rfc6726-compliance-fixes branch from c7306fc to e6bbe48 Compare August 22, 2026 20:01
@jordijoangimenez
jordijoangimenez force-pushed the feature/flute-v2-support branch 4 times, most recently from 6e90d9f to 22baee6 Compare August 23, 2026 07:00
@jordijoangimenez
jordijoangimenez force-pushed the feature/wave3-rfc6726-compliance-fixes branch from 4c3e556 to e6bbe48 Compare August 23, 2026 07:29
@jordijoangimenez
jordijoangimenez force-pushed the feature/flute-v2-support branch 3 times, most recently from 8896a63 to 51b4053 Compare August 23, 2026 12:22
@jordijoangimenez
jordijoangimenez force-pushed the feature/wave3-rfc6726-compliance-fixes branch from 45f4df6 to e90c13d Compare August 23, 2026 12:33
@jordijoangimenez
jordijoangimenez force-pushed the feature/flute-v2-support branch 3 times, most recently from 0395428 to 12119e1 Compare August 23, 2026 15:33
…ault

Change type
  New feature, not for 3GPP MBMS use. This branch is the FLUTE version 2 delta and nothing else.

Basis
  The two versions are separate protocols, not a compatible upgrade.

  RFC 3926 clause 3.4.1: "This document specifies FLUTE version 1. Hence in any ALC packet that
  carries FDT Instance and that belongs to the file delivery session as specified in this
  specification MUST set this field to '1'."

  RFC 6726 clause 11.1: "Therefore, an implementation that relies on [RFC3926] and RFC 3451 will
  not be backwards compatible with FLUTE as specified in this document."

  RFC 6726 clause 3.1, which is why the receive side checks against a configured value rather than
  accepting whatever arrives: "If multiple FLUTE sessions are sent to a channel, then receivers
  MUST determine the FLUTE protocol version, based on version fields and the (source IP address,
  TSI) pair carried in the ALC/LCT header of the packet."

  On the LCT generation, RFC 6726 clause 11.1: "In [RFC5651], these fields MUST be set to zero and
  MUST be ignored by receivers (instead, the EXT_TIME Header Extensions can convey this
  information if needed)."

  On the identifier sequence, RFC 6726 clause 3.4.1: "After reaching the maximum value (2^20-1),
  the numbering starts from the smallest FDT Instance ID value assigned to an expired FDT
  Instance." and "Senders MUST NOT reuse an FDT Instance ID value that is already in use for a
  non-expired FDT Instance."

  On expiry, RFC 6726 clause 3.3: "both a sender and a receiver easily determine to which
  (136-year) epoch the FDT Instance expiration time value pertains by choosing the epoch for which
  the expiration time is closest in time to the current time."

  On a shared Content-Location, RFC 6726 clause 3.4.2: "the element appearing in the FDT Instance
  with the greater FDT Instance ID is considered to declare a newer instance (e.g., version) of
  the same"

  On security, RFC 6726 clause 7.5 takes its service set from ALC, where RFC 5775 requires
  anti-replay support alongside authentication and integrity.

Change
  A per-session FLUTE version, settable on the Transmitter and Receiver, defaulting to 1, carried
  into the ALC parser, the FDT and the receiver's object handling. Every behavioural difference
  below is reached only when a caller selects version 2, so a version 1 or 3GPP session is
  unchanged in every respect.

  Signalling: transmit writes the selected version into the EXT_FDT nibble, receive accepts only
  the configured version, and the RFC 6726 FDT namespace is enabled.

  LCT generation: under version 2 the two bits RFC 3451 used for the Sender Current Time and
  Expected Residual Time fields contribute no header words and nothing is stepped over, so an
  extension placed after the TOI is reached. Under version 1 the RFC 3451 reading is untouched.
  Transmit has always sent both bits zero, since the header buffer is calloc'd.

  FDT Instance ID: version 2 wraps to the smallest expired identifier, refuses one still live, and
  reports exhaustion, which RFC 6726 clause 3.4.1 leaves to the implementation. Version 1 keeps
  RFC 3926's wrap to zero.

  Expiry: read into the era nearest the current time, version 2 only.

  Shared Content-Location: the receiver records which instance declared each file and keeps the
  one from the greater instance ID rather than whichever completed first, version 2 only.

  IpSec sets a replay window. That one is version-independent and benefits both.

  Four further obligations were checked against the specifications and found already met, so no
  code changed for them: EXT_TIME and EXT_AUTH recognition, the RFC 3450 to RFC 5775 move, the FDT
  schema body, and ESP authentication and integrity. README-FLUTE-V2.md records each, how it was
  established, and where the reading is weaker than a test.

  The default is what keeps this safe: 1 is the version TS 26.346 clause L.4.1 references, so a
  session that does not ask for version 2 behaves exactly as it does on the version 1 branch.

Separation, deliberate
  Rebuilt on the FLUTE version 1 compliance branch rather than on the FEC branches, so it carries
  no Raptor and no RaptorQ: zero files of either. The Raptor and RaptorQ test suites are
  deliberately not registered in tests/CMakeLists.txt here, and the reason is stated at that line.

Verification
  T1: 62 cases pass at the build root, 12 of them in the FluteV2 suite, covering both readings of
  the LCT bits, the three branches of the version 2 identifier sequence, and the worked example
  RFC 6726 clause 3.3 gives for the era calculation. Quotations checked with
  tools/verify-citations.py in --strict mode.
  T2: ip xfrm state show on an installed association reports "replay-window 32" beside the enc and
  auth-trunc lines. 32 is the ceiling the legacy attribute expresses, the kernel holding its replay
  bitmap in a __u32; a request for 64 is clamped.

Not in this change
  Congestion control, which RFC 5775 requires for every packet in a session and which this library
  does not implement. It is a building block, not a patch, and until it exists no RFC 6726
  conformance is claimed for this branch and none can be. It is the only remaining item.
@jordijoangimenez
jordijoangimenez force-pushed the feature/flute-v2-support branch from 12119e1 to 82e1433 Compare August 23, 2026 15:41
@jordijoangimenez

Copy link
Copy Markdown
Contributor Author

This pull request: merge it any time after #62

Status: ready. One commit, 12 files, +625/-45. 81 cases pass. Independent of the FEC pair, so it can go before or after them.

What to do

  1. Merge after FLUTE v1 (RFC 3926) and MBMS Download Profile conformance, plus assorted correctness fixes #62, whose branch is its base. Order relative to RFC 5053 Raptor FEC scheme: codec, FLUTE integration, and the missing-symbol accessor #61, RFC 6330 RaptorQ FEC scheme (not 3GPP-mandated, offered as reference work) #64, Tunnel-mode reception, and five object-handling fixes (compression, partitioning, transfer length) #68 and WEBRC congestion control (RFC 3738), unverified: no conformance claimed #98 does not matter.
  2. Do not close Support FLUTE version 2 (RFC 6726), which supersedes the version this library implements #81 with it. This is step one of the three that issue sets out, and Support FLUTE version 2 (RFC 6726), which supersedes the version this library implements #81 must stay open. Version 1 remains the default and nothing here is reachable from a version 1 or 3GPP session.
  3. Keep it to one commit. A pre-commit hook on this branch enforces that, and refused a change earlier this week that belonged on FLUTE v1 (RFC 3926) and MBMS Download Profile conformance, plus assorted correctness fixes #62 instead.

A correction to an earlier version of this pull request's description. It said of RFC 5775 and RFC 5651 that "neither of the newer documents is held by us, so no version 2 conformance can be asserted either way". That was wrong, and it is what kept #81's second step from being attempted for two weeks. Both documents were available. They have now been read against the code, and the finding is on #81: the LCT header does not change between RFC 3451 and RFC 5651 for any field this library uses, so the second step needed four fixes rather than a re-encoding. Three landed on #62, one on #98, none here.

What still blocks a version 2 conformance claim is step three, congestion control, in #98 and untested against a second implementation.


How this set of pull requests came to look like this

When What Why
May 2023 #7, Forward Error Correction, from @autumn-traveller The original FEC contribution. Closed 11 Aug 2026 in favour of a from-scratch RFC 5053 implementation, after the decision to stop harmonising two divergent approaches. Its intent is carried by #61.
11 Aug 2026 #67, tunnel-mode reception + FEC + reception fixes One pull request holding three unrelated subjects, opened from a personal fork. Closed the same day and reopened as #68 from this repository.
11 Aug 2026 The stack below The remaining work split by subject, so each part could be reviewed on its own terms and merged in a stated order.
22 Aug 2026 #87 to #95 opened, then closed the same day Nine single-issue pull requests, an attempt to split the stack further. Each carries a closing comment naming the pull request its work was folded into, stating that the issue it closed is claimed by that pull request instead, and that nothing is dropped. The stated reason was to keep the number of open pull requests down. They still had to merge in a fixed order, so splitting them out raised the count from six to fifteen without making any one of them easier to review.
23 Aug 2026 #98 split out of #62 WEBRC congestion control cannot be validated in this repository. Keeping it in #62 would have forced a reviewer to accept an unverified congestion controller alongside conformance fixes that are ready.
23 Aug 2026 Four commits added to #62, two to #98 A prose read of RFC 5775 (ALC) and RFC 5651 (LCT) against the code, undertaken to scope #81's second step. Findings are listed on #81.

Where the nine closed pull requests went

Closed Its work is now in Issue Declared by
#87 RFC 5053 Raptor codec #61 #1, in part see the note below
#88 missing source symbol ESIs #61 #86 #61
#89 zlib encode and decode loops #68 #77 #68
#90 encoded object transfer length #68 #80 #68
#91 source address binding with a tunnel #62 #82 #62
#92 IPsec netlink socket leak #62 #83 #62
#93 FDT growth regression coverage #62 none, tests only n/a
#94 receiver example output path #62 #27 #62
#95 IPsec IPv6 destinations #62 #85 #62

One correction, @rjb1000. #93 is listed above as "already merged in PR #60". #60 merged the FDT growth fix on 17 August and changed no test file; tests/test_fdt_growth.cpp does not exist on development today. The regression coverage is commit 2750ff0 on #62's branch. Nothing is lost either way, but the coverage rides in with #62 rather than being already upstream.

Every open issue, and which pull request closes it

Closed on merge by Issues
#62 #27, #70, #71, #72, #73, #74, #75, #76, #82, #83, #85, #96, #97
#61 #86
#68 #66, #77, #78, #79, #80
#64, #65, #98 none

Four open issues are deliberately closed by nothing:

The stack, and the order to merge it in

development
└── #62  feature/wave3-rfc6726-compliance-fixes      merge FIRST
    ├── #61  feature/raptor-raptorq-fec              then this
    │   └── #64  feature/raptorq-support             then this
    ├── #65  feature/flute-v2-support                any time after #62
    ├── #68  feature/issue66-receiver-tunnel-mode    draft, see below
    └── #98  feature/webrc-congestion-control        draft, see below

GitHub retargets each child to development as its parent merges. All seven are mergeable, every branch builds clean, and each passes its own suite: #62 67 cases, #65 81, #61 97, #64 114, #68 77, #98 128.

One trap for whoever merges. The heads live in two repositories: #61, #68 and #98 in 5G-MAG, #62, #64 and #65 on a personal fork. The base branch feature/wave3-rfc6726-compliance-fixes exists in both, and the four pull requests based on it resolve it in 5G-MAG, not the fork. Both copies are at the same commit now and need to stay that way; a push to only one of them leaves four pull requests comparing against history that no longer exists.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

Development

Successfully merging this pull request may close these issues.

2 participants